<?php
/**
 * <https://y.st./>
 * Copyright © 2018 Alex Yst <mailto:copyright@y.st>
 * 
 * This program is free software: you can redistribute it and/or modify
 * it under the terms of the GNU General Public License as published by
 * the Free Software Foundation, either version 3 of the License, or
 * (at your option) any later version.
 * 
 * This program is distributed in the hope that it will be useful,
 * but WITHOUT ANY WARRANTY; without even the implied warranty of
 * MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the
 * GNU General Public License for more details.
 * 
 * You should have received a copy of the GNU General Public License
 * along with this program. If not, see <https://www.gnu.org./licenses/>.
**/

$xhtml = array(
	'<{title}>' => 'Poisson random variables',
	'takedown' => '2017-11-01',
	'<{body}>' => <<<END
<img src="/img/CC_BY-SA_4.0/y.st./weblog/2018/10/05.jpg" alt="Trees by the road" class="framed-centred-image" width="649" height="480"/>
<section id="drudgery">
	<h2>Drudgery</h2>
	<p>
		My discussion post for the day:
	</p>
	<blockquote>
		<p>
			I have a library of classes, functions, and constants called <code>include.d</code> (pronounced &quot;included&quot; or &quot;include dot dee&quot;) that I use when writing my code.
			Keeping the functions, classes, and constants in this separate library allows me to reuse them in multiple scripts.
			I&apos;ve been meaning to write a sanity checker for my website&apos;s $a[XHTML] files, but I&apos;ve also been meaning to update the debug scripts for <code>include.d</code> to test for bugs in <code>include.d</code>&apos;s older code that was written before I was methodical about my regression testing (testing to see if formerly-working functionality is broken by later updates).
			The best way to make sure I build the correct tests for the new code I need for use with my website is to have this new testing enforcer written.
			However, the testing enforcer will yell at me and halt the testing suite due to not all the tests for old code being written yet.
			Therefore, I needed to write the testing enforcer, white the code for all the missing debug code it complains about, and only <strong>*then*</strong> write the code I need for use in cleaning up my website along with the debug code for this new functionality.
		</p>
		<p>
			I attend $a[LUG] meetings every week on Thursdays.
			They&apos;re a really informal affair.
			When members need help with their computers, we try to provide that help, but otherwise, we just sort of all work on our own projects while socialising.
			Lately, I&apos;ve been working on the aforementioned debug code during these meetings.
			These meetings are the only time I have during the week that I&apos;m not working on coursework, working my day job, or running errands.
			Due to the nature of the new enforcer, the code it demands from me is code for catching error conditions.
			If <code>include.d</code> fails to recognise an error, it&apos;ll continue processing data as if there is none.
			This is no good, as it allows bad data to be treated as good data.
			While I&apos;ve tested good data quite a bit, in some cases, I&apos;ve failed to make sure bad data is recognised, so as I add new test cases to my suite, more errors in <code>include.d</code>&apos;s code are found so I can correct them.
			This presents three different things that can be modelled using a poisson random variable.
		</p>
		<h3>Debug cases written in a given week</h3>
		<p>
			The first is the number of new test cases I write each week.
			Each week, I may end up helping someone with a problem and have no time to work on my debug scripts.
			I might write zero test cases because of that.
			I might also discover the effects of a bug that&apos;s difficult to locate so I can fix it.
			In these cases, I&apos;m forced to stop writing test cases and go on a bug hunt.
			This slows down progress in writing test cases, though it&apos;s the entire purpose of writing the test cases to begin with.
			I might also get distracted by my fellow members, and not work as efficiently as I otherwise would.
			This almost always happens, and lowers the number of test cases I produce each week.
			We&apos;re a bit of a social gathering, coming together to hang out with like-minded people, though on an off week, everyone is oddly silent and I get more work done.
			I could use a poisson random variable to model the number of new debug cases I write each week.
			I think I usually get about five written, though if we didn&apos;t talk at all and I didn&apos;t discover any new bugs, I could likely finish the remaining test cases in a single meeting.
			This week, I wrote zero test cases because I was too busy to attend the meeting at all.
			The most likely possibilities are clustered around five, but there&apos;s a wide spectrum of discreet values that might occur.
			Any test case I write not complained about by the debugger doesn&apos;t count in this endeavour, so I can only write up to the number of missing test cases in a given week.
			For now, the sample space is the integers ranging from zero through twenty-eight, though that number goes down every week that I successfully write at least one test case.
			This model is only really useful for making the predictions needed to build the next model.
			Without this model, I don&apos;t know where to cluster the likely possibilities in the next model.
		</p>
		<h3>Remaining weeks until completion</h3>
		<p>
			The previous example is a bit boring, as well as arguably useless.
			I could also model how many weeks it will take me to finish though.
			Until I finish the debug scripts, I can&apos;t work on the new feature I need for checking my website for sanity errors.
			It&apos;d be nice to know about how long I have until I can begin working on that.
			This too can be modelled using a poisson random variable.
			As discussed above, I know about what rate I&apos;m completing the test cases at.
			The debug enforcer also spite out a list of cases I failed to test for when I run the debug scripts as well.
			I can count the untested cases, then apply that number to modelling the remaining time I will need.
			It&apos;s possible I&apos;ll finish next Thursday, which we can call Week 0.
			This is possible, though as mentioned above, unlikely.
			It&apos;s also possible I&apos;ll end up unable to write test cases for weeks on end, stretching into infinity.
			The longer the period, the less likely it&apos;ll occur, but it&apos;s still a possibility.
			Most likely, it&apos;ll take me about six more weeks to finish, as I have twenty-eight more test cases to write, so the probabilities are clustered at the Week 5 mark.
			(Week 5 will be the sixth week, as Week 0 is the first week.)
			This time, the sample space is all integers from zero through the week of my death.
			I can&apos;t write test cases after I die, so at that point, we&apos;ll have to consider my work complete whether it&apos;s as tested as it should be or not.
			Without such a model, I have no idea how long it&apos;ll be until I can write the code needed to fix my website.
		</p>
		<h3>Bug discovery</h3>
		<p>
			Lastly, we can model the number of bugs I&apos;ll find by the time I&apos;ve completed my task.
			Due to insufficient testing of my older code, I&apos;ve left a number of bugs in it.
			When given good data, <code>include.d</code> processes it correctly, as far as I know.
			Much testing went into making sure of that.
			However, bad data is often not recognised as bad.
			As I write the missing debug cases, I&apos;ve been discovering and fixing such bugs.
			By modelling the number of bugs I will find, we can make a guess at how desperately the missing bug tests were needed.
			Hopefully, that&apos;ll motivate me to keep up with proper testing.
			I&apos;ve improved my testing behaviours over the past few years, but in the beginning, I really wasn&apos;t as good about testing things as I should have been.
			I might find no more bugs, and I might find thousands more bugs from one test case.
			The sample space is the integers from zero to infinity.
			At my current rate of bug-finding though, I&apos;ve got twelve more bugs that I&apos;ll run across, as I find about two bugs per week.
			That assumes my rate stays constant though.
			It&apos;ll very likely be off by a couple in one direction or another.
		</p>
	</blockquote>
</section>
<section id="cargo">
	<h2>Bicycle cargo box</h2>
	<p>
		I tried to install the cargo box on my bike yesterday to test it out, but found the bolts didn&apos;t fit where I thought they were supposed to.
		I assumed the bolts were the wrong size for my bicycle, but one a hunch, I tried fitting them on the bike the box came off of.
		They don&apos;t fit there, either.
		When my mother removed the cargo box, it left me with no way to know how to get the thing back on.
		Until she shows me how to install the box now, assuming she even remembers how, the thing is useless.
	</p>
</section>
END
);
